Size Change: -22.7 kB (-2%)

Total Size: 1.42 MB

_{compressed-size-action}

The bot reports gzipped sizes, there the improvement is not 10x, but merely 57%. The big TZ data compress well.

Performance tests also show improvement when it comes to loading the editor:

┌──────────────────────┬──────────────────────────────────────────┬───────────────┐
│       (index)        │ 1bfeb9cd1d2d123dcc5bf168317e5a90190021b7 │     trunk     │
├──────────────────────┼──────────────────────────────────────────┼───────────────┤
│    serverResponse    │               '245.22 ms'                │  '251.82 ms'  │
│      firstPaint      │               '256.56 ms'                │  '333.02 ms'  │
│   domContentLoaded   │               '682.74 ms'                │  '728.68 ms'  │
│        loaded        │               '683.54 ms'                │  '729.62 ms'  │
│ firstContentfulPaint │               '1265.06 ms'               │  '1316.5 ms'  │
│      firstBlock      │              '13108.84 ms'               │ '12927.98 ms' │

Too bad we don't report the ± variances and can't estimate how significant and non-random the changes are.

Too bad we don't report the ± variances and can't estimate how significant and non-random the changes are.

I definitely agree; insufficient analysis can sometimes suggest the wrong thing. That being said, the numbers shown here don't raise much suspicion to me. A massive reduction in JS to be parsed and compiled (and what matters there is uncompressed size, not gzipped size, so we're talking 1/10th) is bound to have a measurable impact on interactivity metrics. Since this JS loads as part of the critical path, I would expect that to reflect in first paint and every subsequent time-based metric.

Assuming that the existing functionality is preserved, this is an excellent interim improvement as we hopefully move towards a solution that doesn't involve shipping timezone data down the wire at all, but instead relies on the system's.

Fantastic work, @jsnajdr! 🙌

Could you please add some testing instructions to the PR?

All places that use getDate or dateI18n are potentially affected. And are supposed to show dates with the right offset when you switch your site to a certain timezone. Places like this:

But it seems to me that post publish dates behave differently -- it shows as published at 5:48 am, no matter which timezone I choose. Even without this PR. So maybe that date has a different meaning, TZ-agnostic.

Could you please add some testing instructions to the PR?

All places that use getDate or dateI18n are potentially affected. And are supposed to show dates with the right offset when you switch your site to a certain timezone. Places like this:

But it seems to me that post publish dates behave differently -- it shows as published at 5:48 am, no matter which timezone I choose. Even without this PR. So maybe that date has a different meaning, TZ-agnostic.

Yeah, that was my understanding as well, but I tried both with and without the timezones and nothing changed for my tests. It would be nice to confirm that there's an area that actually is directly affected by this, and to reflect this in testing instructions so we can ensure we understand the consequences of the PR. WDYT?

It would be nice to confirm that there's an area that actually is directly affected by this

Yes, I also have some open questions like this -- it's possible that Gutenberg itself doesn't use the bundled timezones at all. Because the date package creates a special WP_ZONE timezone, using data from server-generated inline script:

And uses that as the default timezone when formatting dates.

But that's bad because this timezone definition is incomplete, the offset: 2 value is valid only for today, June 16, because we're in a daylight saving time right now. If I use this data to format a winter January 16 date, it will have wrong offset, the right one is offset: 1. You need a full CEST zone definition to format all dates correctly.

but you can have a post written earlier (in 1997 for example) and that's fine.

Then it will probably use the 2003 rules which is not entirely bad. The typical rules change between 1997 and 2003 is that the DST switching times have shifted to be a week later or earlier.

Perhaps @youknowriad could be able to help? He worked on #841 back in the day.

Yes, I also have some open questions like this -- it's possible that Gutenberg itself doesn't use the bundled timezones at all. Because the date package creates a special WP_ZONE timezone, using data from server-generated inline script:

If I remember correctly, we do this indeed for i18n reasons. These labels come translated from the backend.

If I remember correctly, we do this indeed for i18n reasons.

Would be great if someone can provide more info about this if they have it at the top of their head. We'll most definitely be digging into understanding all the impact that moment.js has, since at some point we want to get rid of it completely, but for the time being, it would be nice to understand the actual utility of the timezone data. I've been testing in a few of those date components in Bulgarian and nothing seems to change when I stop loading the timezone data.

@tyxla WordPress allows you to tweak your timezone settings, date format and time format from the "settings -> general" wp-admin page. and these changes need to be reflected in the UI and I think that's what this timezone is about.

@tyxla WordPress allows you to tweak your timezone settings, date format and time format from the "settings -> general" wp-admin page. and these changes need to be reflected in the UI and I think that's what this timezone is about.

Thanks for confirming, but since I knew that already and I've been tweaking those settings, the dates always appeared in Bulgarian properly for me, regardless of whether I'm loading timezone data or not. Hope that makes more sense as to where the confusion comes from.

If by time zone data you mean moment-timezone, than yeah maybe that is useless since we always define on in WordPress but there are questions about third-party cases that don't rely on the "WP" timezone. (I hope I'm understanding this properly)

If by time zone data you mean moment-timezone, than yeah maybe that is useless since we always define on in WordPress

That's what I mean, yes. Thanks for confirming - it's worth knowing that we can explore NOT loading the huge moment timezones blob at all. @jsnajdr is this something you'd like to try out?

but there are questions about third-party cases that don't rely on the "WP" timezone.

I'd love to understand more about these cases - do you happen to have an example? We could benefit a lot from making the moment timezone data optional or opt-in.

I'd love to understand more about these cases - do you happen to have an example? We could benefit a lot from making the moment timezone data optional or opt-in.

Not much to be honest, I just have very vague memories that at some point we attempted changes about how "moment" locales were handled and it broke some plugins (it was something about locales being define globally in the moment singleton or something), but to be honest, that's very far in the past. Not sure it should stop any explorations.

Not much to be honest, I just have very vague memories that at some point we attempted changes about how "moment" locales were handled and it broke some plugins (it was something about locales being define globally in the moment singleton or something), but to be honest, that's very far in the past. Not sure it should stop any explorations.

Sounds great!

@jsnajdr - in that case how do you feel about keeping the span minimal - like for this year only for example? Hopefully, that may keep the 3rd party plugin use case working while getting us a very solid file size improvement.

I've been testing in a few of those date components in Bulgarian and nothing seems to change when I stop loading the timezone data.

It seems indeed that the timezone data are not used, at least for post dates. And it leads to wrong results. The Core REST API (wp/v2) returns a date field with no timezone or offset specified, like 2023-02-02T05:48:00. That's 5:48 am on February 2, in the CET zone, winter time. In UTC this is 4:48 am because the winter offset is +1h. But the WP timezone sent from server specifies a +2h offset, because it's summer time now, and this date will be interpreted as 3:48 am UTC.

Here's how my testing post looks like in the wp-admin post list:

but in Gutenberg, the PostScheduleToggle component will show time offset by one hour, and is in conflict with what the DateTimePicker shows.

That's because DateTimePicker displays the date as-is, without trying to interpret the time zone. I think it will start also showing bad results once the local (browser) time zone is different from the server (site) zone.

Ideally, we shouldn't use the timezone.offset from the server settings, but the timezone.abbr name, and pass that name to moment.tz. moment.tz knows all the rules for the zone, not just one offset, and will be able to handle things correctly.

Ideally, we shouldn't use the timezone.offset from the server settings, but the timezone.abbr name, and pass that name to moment.tz. moment.tz knows all the rules for the zone, not just one offset, and will be able to handle things correctly.

Seems like this is work for another PR. This one can be merged separately IMHO.

The only thing that gets me anxious is the 2030 limit. Perhaps we can change it to be the current year + 5 years, or + 10 years?

And then for the future, I'd love us to explore getting rid of moment.js completely. Temporal is at stage 3 and we can start experimenting with it already. One way to do it could be to create a completely new date package and migrate all Gutenberg usages to the new one. The old one could remain indefinitely in a deprecated state, but will be unused by the core project.

The only thing that gets me anxious is the 2030 limit. Perhaps we can change it to be the current year + 5 years, or + 10 years?

I changed the limit to 2040, 10 years more. I don't like the idea to calculate the year dynamically based on the current year. That makes the builds non-reproducible. On the same commit, you get different output on different dates. Also, the build machine's date can be completely wrong, like 01-01-1970.

Flaky tests detected in bb62463.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5419716524
📝 Reported issues:

• [Flaky Test] should not allow blocks to be inserted in inner blocks #44341 in specs/editor/plugins/cpt-locking.test.js